home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-crocker-pci-00.txt
< prev
next >
Wrap
Text File
|
1993-06-16
|
23KB
|
620 lines
Internet Draft PCI (Expiration: 3/94)
D. Crocker
Network Working Group D. Crocker
Internet Draft <STIF> Silicon Graphics, Inc.
Expiration <3/94> 9 June 1993
Encoding for Personal Contact Information (PCI)
STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. (Note that other groups may also
distribute working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate is use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the Internet Draft abstract listing contained in the
IETF Shadow Directories (cd internet-drafts) to learn the current
status of this or any other Internet Draft.
SUMMARY
Extensive use of Internet electronic mail demonstrates a need to
be able to communicate various descriptive information about
participants. The information ranges from telephone and postal
addressing, to an indication of the media supported by their
electronic mail and information processing environment. This
specification provides a basis for encoding such "PCI" business
card information by using the STIF [CROC93] syntax.
A MIME Content sub-type is defined for carriage of PCI
information.
TABLE OF CONTENTS
1. INTRODUCTION
2. MIME Content-Type for Carriage of PCI Information
3. PCI FRAMEWORK
3.1 Basic Syntax
4. ADDRESSING DETAIL
4.1. Electronic Mail Detail
4.2. Postal Mail Detail
4.3. Facsimile Mail Detail
4.4. Telex Mail Detail
5. DESCRIPTION DETAIL
6. CAPABILITIES DETAIL
7. REFERENCES
8. SECURITY CONSIDERATIONS
9. ACKNOWLEDGEMENTS
10. CONTACT
A. Example of Personal Contact Information
1. INTRODUCTION
Extensive use of Internet electronic mail demonstrates a need to
be able to communicate various descriptive information about
participants. The information ranges from telephone and postal
addressing, to an indication of the media supported by their
electronic mail and information processing environment. This
specification provides a basis for encoding such "PCI" business
cardinformation by using the STIF [CROC93] syntax.
EMail often contains a set of information headers, or free-format
text, at the end of the message intended to convey various
information about the originator of the message. There is no
formal specification which permits automated exchange of such
information so that it can be incorporated into an on-line
information base. Further, there is no way for a sender to
provides recipients with similar information about each other.
At its simplest, the PCI/STIF/MIME mechanism permits the exchange
of "business card" information in an automated fashion. Hence,
its benefits should be an on-line equivalent to that derived when
business associates exchange contact information.
This specification provides a detailed structure for encoding the
wide range of contact and description information needed by
communicants. It includes fine-grained specification for
delivery through various media and specification of the human
communication media support available to a participant.
A MIME Content-type is defined for carriage of PCI information.
2. MIME Content-Type for Carriage of PCI Information
PCI information is encoded with the STIF syntax, and can be
carried in MIME [BORE92] messages:
MIME type name: TEXT
MIME subtype name: PCI
Required parameters: none
Optional parameters: charset = xxx
This defines the alternate STIF character set. Legal
character sets are the same as defined in MIME.
Encoding considerations:
Alternate character set characters, and some US-ASCII
characters cannot be sent through some transport services
directly. Transports that do not support such data
should enocode the data appropriately. Where possible,
it is recommended that quoted-printable be used, to
preserve some level of human-readability.
Security considerations:
See separate section in the documen t.
Published specification:
This document and its companion, Structured Text
Interchange Format (STIF), with additional specification
at the end of this section.
Rationale:
Provides human- and machine-processable means of encoding
common personal contact information. This will permit
automated processing, such as for maintaining personal
files of contact information.
Contact-info:
See Contact section, below.
Detail specific to MIME-based usage:
Within a MIME body-part, PCI data are to be encoded as a
series of headers, in the style of RFC 822. Each header
has a name, which serves as the reference key to a set of
data. Usually, the key should be a version of the
person's name which has been stripped of seconday text,
such as titles and salutations:
pci-entry = *( pci-key ":" pci-info )
pci-key = field-name
; specifies the string to be used
for filing the entry, usually
name minus titles, etc. >
field-name = < As defined in RFC822>
3. PCI FRAMEWORK
PCI permits structured, extensible specification of information
about a person or some other "reachable" resource. Use of the
STIF syntax permits machine processing of the PCI content. PCI
entries are specified one per STIF Header, rather than in the
compressed, list-oriented format of RFC822 which allows multiple
addresses per line.
Information is specified by a set of STIF fields which are named
from a single, flat name space. Extensions to this document are
to be registered with IANA, as described in the MIME
specification [BORE92]. For convenience, this document discusses
the initial set of PCI fields in three different sections. The
first provides information about various addressing alternatives,
including electronic mail, postal mail, facsimile transmission,
and telex transmission. The second set of PCI fields cover
descriptive information about a person, such as their personal
name, organizational affiliation, title, and telephone contact
number. The third set of information specifies the capabilities
of the person's electronic mail service. This allows the sender
or agent software for the recipient to determine what alternate
routing or gateway translations are to be provided.
3.1 Basic Syntax
pci-part = 1*( pci-descrip / pci-capable / pci-nest )
; described below
pci-nest = nest-name "<" pci-info ">"
; PCI-specific use of STIF nesting
capability
nest-name = "work" / "home" / x-pci
x-pci = "x-" word
; private extension
Note that RFC 822 lists of addresses, within a field, have been
modified to be lists of STIF headers. PCI entries may contain
two types of information:
1. Addressing Detail provides basic contact information,
sufficient to allow contact via a variety of transport
mechanisms, such as postal, telex and email.
2. Description Detail provides information about the
addressee, some of which may be required by some media, but which
may otherwise be of interest. The addressee's name and the name
of their organization are examples of such information.
3. Capabilities Detail provides guidance about the
addressee's support of various on-line media and, possibly,
conversions they would prefer when they lack a capability. For
example, they may have a fax machine but not have on-line
graphics capabilities and they may wish that graphics body-parts
be sent to them via facsimile. (This specification does not
dictate behavior by electronic mail transport services, so that
use of capabilities information is outside of the scope of this
document.)
4. ADDRESSING DETAIL
4.1. Electronic Mail Detail
Specification of electronic mail addresses is similar to the
style used for RFC 822-based encoding, except that reference to
the formal, presentation name of a person is separated into its
own field, since it may be used without any reference to email.
Further, an email address may be characterized as to type. This
is intended to allow user agents to perform contingent actions,
depending upon the type of email address. For example, a reply
to a message which includes an email reference to a list or
bboard may cause the user agent to obtain confirmation from the
sender, so that such addresses are not included in replies
automatically and possibly by accident.
email = "email" ":" addr-spec
[ "/" email-type ]
; standard RFC 822 on-line address,
without the human name portion
(instead placed in Name field)
email-type = "person" / "list" / "list-owner"
; distinguish the type of mail
address referent.
; a "list" distributes copies to
multiple recipients
; "list-owner" directs the message
to the address responsible for
administering the named list
4.2. Postal Mail Detail
The specified fields refer to typical categories of postal
information that are used. Note that such information is order-
dependent to the Postal Service. For example, in the United
States, an address which contains both a street address and a
post office box address is delivered to whichever address is
"lower" on the envelope.
Courier-delivered mail specification is treated as a type of
postal delivery, although it may require additional information,
such as the specific courier agency to be used. Also, some
courier agencies require the specification of the recipient's
telephone number.
Since the service provided by one electronic mail gateway may
differ from that of another, or the authorization to use it may
be restricted, specification of a particular postal gateway is
permitted.
paper = [name]
[org]
paper-set
[paper-gateway]
paper-set = internal / postal / courier / printer
<< How would you like the printer reference to work?? >>
internal = 1*2( dept / mailstop )
; sufficient for routing within an
organization, but not for routing
by public postal system
mailstop = "stop" ":" ephrase
; address _within_ an organization
postal = [internal]
drop
code
geo
drop = 1*2( 1*2(street) / pobox )
; Street or Post Office Box or both
; Note that the last to appear will
be used by the postal service
street = "street ":" ephrase
pobox = "box" ":" ephrase
; postal box
code = "code ":" word
; zip code, postal code, or the
equivalent postal routing string
geo = "geo" ":"
city-val "/" region-val "/" country-val
; geographic location
city-val = ephrase
region-val = ephrase
; state, province, or the equivalent
country-val = word
; conforms to the relevant
international reference standards
courier = postal
; courier-delivered paper mail uses
the same base of information as
postal
[carrier-name]
[account]
[deliver-by]
[phone]
; phone number of recipient usually
is required
carrier-name = "carrier ":" ephrase
; if a specific company's service is
required
account = "account ":" ephrase
; string which specifies the account
to which charges for usage are to
be made.
paper-gateway = "paper-gate" ":" addr-spec
; Internet address for gateway
system to the paper-based
service
; If deliver=paper and no paper-gate
is specified, the underlying
email transport service must
already know of such a gateway
4.3. Facsimile Mail Detail
Facsimile addresses are easily specified, since they consist only
of a telephone number. However, transmission of facsimile may
require essential configuration information, such as the degree
of precision to the image to be sent or variations in the cover
page to be used. As with postal, the specification may indicate
a particular gateway service that is to be used.
fax = [name]
fax-phone
[grain]
[cover-name]
[phone]
[postal / internal]
[pagecount]
[instruct]
[subject]
[fax-gateway]
; optional info needed for cover
page
; originator User Header must supply
info for cover page, also
fax-phone = "fax ":" phone-number *( "/" phone-number )
grain = "grain" ":" ("regular" / "fine")
cover-name = "cover ":" ephrase
; name of cover page template, if
more than one cover page allowed
pagecount = "page ":" number
; number of pages, _including cover
page_ in the fax
instruct = "instruct ":" ephrase
; handling instructions for
facsimile operator
fax-gateway = "fax-gate" ":" addr-spec
; Internet address for gateway
system to the facsimile service
; If deliver=fax and no fax-gate is
specified, the underlying email
transport service must already
know of such a gateway
4.4. Telex Mail Detail
telex = telex-addr
[answer]
[telex-gateway]
telex-addr = phrase
answer = phrase
telex-gateway = "telex-gate" ":" addr-spec
; Internet address for gateway
system to the Telex service
; If deliver=telex and no telex-gate
is specified, the underlying
email transport service must
already know of such a gateway
5. DESCRIPTION DETAIL
A small set of initial descriptors for an addressee are defined
here. The set is by no means intended to be definitive. Rather,
it is intended to be indicative of the range of such information
that may be useful and appropriate to specify.
a-descrip = name
/ title
/ org
/ department
/ phone
/ motto
/ note
name = "name" ":" ephrase
; personal name of addressee
title = "title" ":" ephrase
; their position within affiliated
organization
org = "org" ":" ephrase
; name of affiliated organization
dept = "dept" ":" ephrase
; name of work group, within
affiliated organization
phone = "phone" ":" #phone-number
; voice contact phone number for
addressee
phone-number = < international telephone number, conforming
to f.103 international telephone number
format >
; e.g., +1 408 249 6205
motto = "motto" ":" ephrase
; descriptive text, associated with
addressee, work group, or
organization
note = "note" ":" ephrase
6. CAPABILITIES DETAIL
A sender may choose a delivery address or medium based upon
knowing the capabilities of the recipient. Similarly, an
electronic mail gateway may choose particular behaviors, such as
encoding formats, based upon such knowledge. Such information
may be accessible through dynamic query of a directory service.
However, this may not be possible. An alternative is to allow
the addressee's descriptive information to contain specification
of the range of media support available to that addressee. For
simplicity, this specification simply provides for listing the
range of MIME content types and sub-types that the addressee's
system can support.
Since stif supports aggregation of references within nested
subsets, <a-capable> specifications may be used for _each_ of
the nested sets of addressing information. A user's different
mailboxes may have different capabilities.
a-capable = "support" ":" 1#support
; set of MIME content types/sub-
types that are supported by this
addressee's email system
support = type "/" subtype
type = < MIME content-type value >
subtype = < MIME content sub-type, as appropriate to
the indicated type >
7. REFERENCES
[BORE92] Borenstein, N. & Freed, N., "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for
specifying and describing the format of Internet
Message Bodies. March, 1992, Network Information
Center, RFC 1341.
[CROC82] Crocker, D., Standard for the format of ARPA
Internet text messages. August, 1982, Network
Information Center, RFC 822.
[CROC93] Crocker, D., Structured Text Interchange Format
(STIF). Draft, May 1993.
8. SECURITY CONSIDERATIONS
This specification covers data encoded within a portion of an
email message. It contains addressing and source-identification
information which is not specially authenticated. No special
provision is made for confidentially of the data. No other
security-related concerns apply.
9. ACKNOWLEDGEMENTS
STIF developed out of a series of conversations, but was
initially focused exclusively for use as enhanced electronic mail
headers. Steve Crocker suggested separating the information for
use as a personal contact, or PCI, information base. Details for
facsimile specification were provided by Alan Katz and Jim
Knowles. Additional review and comments were provided by
Nathaniel Borenstein, Steve Crocker, Ned Freed, Keith Moore,
Marshall Rose and Erik M. van der Poel
10. CONTACT
name: David H. Crocker;
work <email: dcrocker@sgi.com;
org: Silicon Graphics, Inc.;
street: 2011 N. Shoreline Blvd.;
box: 7311;
geo: Mountain View / CA / US; code: 94039-7311;
phone: +1 415 390 1804; fax: +1 415 962 8404>
A. Example of Personal Contact Information
It is common for Internet mail to contain extensive information
about its sender. For example:
From: "Ole J. Jacobsen" <ole@Csli.Stanford.EDU>
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 962-2515 (Office) +1 415 998-4427 (Pager)
Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home)
X-Comment: Ignore error messages for "ole@radiomail.net"
Ole J Jacobsen, Editor & Publisher ConneXions--The
Interoperability Report
Interop Company, 480 San Antonio Road, Suite 100
Mountain View, CA 94040,
Phone: (415) 962-2515 FAX: (415) 949-1779
Email: ole@csli.stanford.edu
When encoded as a PCI header, this becomes:
Ole J Jacobsen:
name: Ole J. Jacobsen
email: ole@csli.stanford.edu;
work <title: Editor & Publisher;
org: Interop Company;
dept: Connexions -- The Interoperability Report;
street: 480 San Antonio Rd., Suite 100;
geo: Mountain View / CA / US; code: 94040;
phone: +1 415 962 2515; fax: +1 415 949 1779>
home <phone: +1 415 550 9427; fax: +1 415 826
2008>
mobile <phone: +1 415 990 9427; pager <phone: +1 415
998 4427> >
note: Ignore error messages for "ole@radiomail.net"
Note that the entire entry is tagged with a canonical form of the
person's name. This tag is different from the formal
presentation string for that person's name. That is, name is
different from the header-name for the header containing the name
field. Leading and trailing information, such as "Dr." or
"Ph.D." and "Jr." should be removed from the header-name, to
faciliate use of this string as a database storage and search
key.